那一天，人類終於回想起了，曾經一度被他們所支配的恐怖，還有背囚禁於鳥籠中的那份屈辱那一天。
— 《進擊的巨人》，諫山創
好其實跟進擊的巨人完全沒有關係（毆飛）。
這篇基本上完全是給leader看的，如果你是那種覺得效率與工程文化至上，覺得去了解每個團隊成員或跟他們閒聊是浪費時間的人，那建議你可以看看這篇文章。因為或許你與過去的講者一樣，都在建立一種culture of fear的文化。
講者利用自己的經驗來講解leadership。當她成為leader時建立的文化是culture of fear，直到後來慢慢學習改進才變成culture of trust，以下就是她自己的一些個人經驗。
速度
身為leader你要讓自己變成沒耐心的人，這裡主要講的是那些會拖慢團隊效率的事情。因為工程師們很享受做出自己看得到或感受得到的東西，如果有流程會拖慢他們速度，他們就會覺得很不爽。例如發佈新的feature，如果部屬流程太過繁瑣或太過手動，你就要想辦法幫助他自動化讓他們不要一直浪費時間在這些瑣碎的事情上。
架構（Structure）
好的架構是你要讓大家可以快速獲取需要的訊息。相信大家都可以理解好的code structure可以讓你快速讀懂程式邏輯，而不好的則會讓你花了很多時間研究還是看不懂在寫什麼毛。不過這裡講到，架構的產生通常是根據一系列的失敗與修正之後獲得的結果，所以在此資訊透明變得很重要，不然大家無法得知自己這個流程的核心價值是什麼，就變成盲從而已。
她這裡提到了個有趣的點，當初她在Four Square公司裡建立career ladder的標準時，嘗試去寫的比較模糊，為了讓大家不要那麼有壓力，不要為了做某些事情而作。但最後卻導致大家更有壓力，因為大家不知道要怎麼做比較好。所以講者重新修正了這套標準，給了比較實在的範例（如果有興趣的人可以看看這裡。）
所以為了產生好的架構，必須要不斷從失敗學習，去review與改進你的流程。而建立架構與流程的重點在what而不是how。因為人非常不擅長follow太過detail的步驟，你寫太detail反而會讓大家不知所措。相對的機器其實很擅長follow明確的步驟，所以如果真的可以寫出細部的how，那想必也能夠自動化。
連結性（Relatedness）
你在是IC role的時候可能不覺得這件事很重要，也不喜歡跟人家合作。但如果你身為一個leader，只在乎技術這種效率至上的想法是不行的，因為大家都是人，建立信任關係能夠提昇團隊的成長與效率。而要達成這件事，你就必須讓每個人覺得他們是像「人」一樣被對待，也不需要對於犯的錯誤感到羞愧，也不需要擔心問錯問題，這樣一來團隊才能發揮最大價值。
另外關於建立安全的環境，一個很簡單的方法是，勇於承認自己的錯誤。讓大家理解犯錯是可以的，每個人都會犯錯，所以沒有必要對於自己的錯誤感到羞愧。
一對一（one-on-one）
1-1重點不只是詢問進度，討論工作上的事情，更是你拉近與團隊成員關係重要的一環。即使你真的很不想做，你可以就練習「假裝」你在意這些東西，通常開始假裝後，你就真的會開始在意這些事情了。
衝突
無論你是對於衝突的態度是喜歡或是不喜歡，都必須練習擁抱衝突。因為衝突是激發不同思維重要的一環。當然你也不能讓衝突太過兇猛（aggressive），不然大家會不敢有任何衝突，那就會造成反效果。而實際上要做這件事，最簡單的是把衝突換成好奇，與其直接拒絕別人的意見，不如多問一些細節，進而了解別人是怎麼想的，就不會讓整個衝突本身看起來很火爆，而且也能達到相同的目的。
會議
開會的目的其實就是為了合作，因為我們相信多人協作會比個人作業帶來更大的效益。但基於合作理由，我們必須要開會去協調與取得共識。或許很多人覺得開會很無聊，所以想盡辦法讓會議變得有效率，但其實更重要的是大家要好好利用會議的時間來討論事情與了解彼此。如果開會的成員對於會議內容都沒什麼意見，要碼是會議根本就沒有必要開，要碼是大家沒有好好利用會議來達成溝通的目的。身為一個leader，你必須要想辦法在會議上讓大家討論問題，吸收大家的意見，了解大家的感受。並創造一個環境讓大家能夠暢所欲言的討論。
最後她說到：同理心其實是個leadership的技能，是可以後天學習的。所以如果你是leader，花點時間鍛鍊你的同理心，了解你自己的想法，也了解你團隊的想法。
作者Camille Fournier其實是著名的The Manager's Path一書的作者，書中講述了不同階段的leader所要做的事情的差異，算是Engineering Leadership近年來非常著名的一本書。只是我自己私心覺得作者的寫作方式並不是那麼好的抓到重點，或許就跟這篇演講一樣，可能有很多點你會認同，但是看完之後可能不太會記得清楚講了什麼。
以下就基於她講的內容在附上一些自己的想法：
其實公司大了自然會有很多繁文褥節，為了scale其實往往需要犧牲個人的效率。例如以前想要發佈東西就隨時發佈，但現在還有複雜的發佈流程，必須要有ticket附上release cycle，加各式各樣的tag，跟寫下發佈的相依性，如果不在常規時間發佈還要寄信寫一堆報告。對於像我這種看著流程改變的人其實很容易適應，但是對於新人就會覺得這些事情很沒必要。導致最後他們常常會東漏西漏少加tag或少寫東西，必須要一直戳他們去補齊。
但也是完全可以理解為什麼大家會怎麼難接受這些流程，畢竟光是要「解釋」發佈流程就要花可能至少半小時看長長的文件。我都懷疑到底哪個新人看完會真的記得這些。
一方面我們希望讓這些用戶知道時代背景所以才能理解這些事情的重要性，但另一方面文章內容太長或者沒有感觸，大家也很難花時間去理解內容。而這中間的平衡要如何拿捏，我自己覺得還是個非常的困難Orz。
關於1-1我真的是有深刻的體悟，我去年帶團隊的時候也覺得1-1沒什麼必要，反正成員不太多，我也可以掌握大家工作進度與狀況，那好像有這個每一兩週一次的sync-up好像沒什麼必要。但在我聽取某個前輩經驗說1-1可以幫助大家設定目標後，我就發現1-1的好處真的是超級多。雖然到了最後「幫大家設定目標」這件事情並不是做的很好，不過我卻從中獲得了許多的啟發與自我成長。
因為就像講者說的，1-1還有一大部分重點是你要與你的成員建立連結，問問他們工作之外的事情，試著去了解別人的真實想法，知道他們在乎什麼不在乎什麼。而這其實會大大影響你跟他們溝通的方式。很多人事情做不好不是能力不好，只是他們的priority跟你的不同，所以你可以嘗試使用對方的priority去跟他溝通，就有機會比較有效率些。
而同時1-1也是個很好的complain的地方，我都跟我的member說我很喜歡聽你們抱怨事情，因為這代表你們對我的信任，也可以從抱怨中獲得很多靈感來改進大家的工作方式。
其實對於衝突的態度我一直是能躲則躲，也是我的弱項之一。
還記得之前在準備面試的時候，有一類問題是關於解決衝突，我那時候就在想好像在S社一路順遂沒什麼可歌可泣的衝突。大部分都是在跟別的team吵架，但是對於我老闆或team成員就真的想不太出來，不知道是真的都沒有衝突還是如何。
但總得來說我就是個害怕衝突的人，通常在要開始吵架前我就會先自我放棄。有時候接受別人的意見目的不是因為真的接受，只是懶得跟別人吵架而已。即使在衝突中，也往往難以控制自己的情緒Orz，而忘了我們目的是為了找到共識，而不是要講贏別人。
不過講者講了一個方式是把衝突換成好奇心，去理解別人是怎麼思考。這樣或許對我來說是個蠻可以接受的思維方式，未來可以嘗試看看。
iThome鐵人賽
看影片追技術